DTI's Door Access Control System (AKA DTI's Zombie Defense System)
At DTI we’re always on the lookout for the ever-present dangers imposed on modern society by Zombies. With that in mind, we wanted to better protect ourselves by implementing an access control system for our building. In the span of one week we've designed a fully functioning access control system for our building that allows us to see out our front door, be alerted when visitors arrive, and remotely grant the visitor access. No more worrying about who is walking in while we're hard at work in the back. DTI's access control system also enables employees entry into our building using prox-cards, which work from inside pants pockets, backpacks or purses, all while recording the entries. The following is our attempt to protect ourselves from a zombie invasion.
System Overview
We’ve been wondering if there was a way to incorporate our existing USB hardware into an access control system for buildings. It turned out to be rather simple. In the time span of one week, we developed a fully functioning access control system for our building that allows us to see out our front door, be alerted when visitors arrive, and remotely grant the visitor access. It’s also able to allow us entry into our building using prox-cards all while recording the entries.
The system has three distinct software components and utilizes seven different hardware components. There is an administrative application that is used to maintain the users who have access to the building, a client application that provides functional requests for the server application which is in charge of the application.
The client application has a functionality that can be accessed by right-clicking on the icon that is stored in the systray in Windows. There are five commands that clients can issue to the server: Reset Device, Update Codes, Peek, Open Door, and P/P Challenge. Reset Device is an administrative task that tells the USB device to reset itself should anything be acting amiss. Update Codes is a command that queries the database for currently active users and updates the USB device with the prox codes associated with those users. This is done so that if connection between the host and the USB device or between the host and the database are lost the USB device uses its internal memory to authenticate prox-card users and open the door. In other words, it’s a back up if the system fails. Peek queries the server for a picture of the webcam. Open Door is a manual way of opening the door. P/P Challenge is a fun easter-egg in the application that allows employees to issue ping-pong challenges to each other.
The menu for the client software.
The server application handles all the requests from the USB Device as well as the client applications. When a visitor presses the doorbell attached to the application the buzzer sounds and it alerts the USB Device to his/her presence. The USB Device then takes the person’s picture and sends it to all of the clients and waits for either a timeout or an acceptance or rejection notice from one of the clients. If the person is accepted by one of the users the door unlocks. The server is also responsible for authenticating prox-card entries with the database and it handles the ping-pong challenges.
The seven pieces of hardware involved in the system are: the host pc, the USB Device, a doorbell, a buzzer, a lock, a prox-card reader, and a USB webcam.
The system was developed using our PICAPI api. It provides a streamlined method for communicating between the embedded c code and the VB.Net code via the USB protocol.
System Development
The real significance of this system is the speed of development. Most of the time spent on the development was finding a small computer to serve as the host and installing Windows XP on it. The second most time consuming aspect was actually affixing the lock to the door. With that said, it leaves the actual software development of the system a distant third for time spent.
DTI has developed several components that aid in our development. For purposes of keeping to the idea of locking system I’m going to skip over one of the most important parts: BaseClasses (it provides us with a very simple way of accessing data from a database) and briefly describe the CommBase component.
CommBase is a very simple component that gives developers access to quick client and server objects. You can see all the components a developer can drag and drop onto a Windows Form in Fig. 1. To make the clients and the server on the host pc communicate a server object was dragged onto the form for the server application and a client was dragged onto the form for the client application. Then using the properties window, a few simple settings where entered and DONE!
Components that are able to be dragged onto a windows form.
The properties for the server.
The properties for the client.
The next important component was the WebCamCapture component, originally written by Philip Pierce. We did have to modify it to enable the capture of images since the original code only had the application work as a pseudo-video camera. With this component we are able to connect to a USB Webcam and call the takePicture method and we get a picture of our visitor (or initiate a lock down if that visitor is a zombie).
The final component, our PICAPI, honestly deserves its own section. If you ever need help developing full database to hardware systems, this component is a must.